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The present invention relates generally to viewing 
!~j the effect of changes to indexing designs for database 

tables. More particularly, the present invention 
relates to using virtual tables and virtual indexes for 
2 0 determining optimization plans for database queries 
when indexes for the database tables are changed. 



Background 

Achieving and maintaining simple and efficient 
access to computer data is a goal shared by most 
computer users. In addition, as the processing power 
of modern computers increases, greater amounts of data 
may need to be organized and stored for the user. One 
system for organizing computer data is the database, 
which is generally recognized as a group of logically 



25 



30 
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related information objects or files stored together in 
some recordable medium without unnecessary redundancy. 
The database preferably serves various applications or 
programs, and facilitates access by these applications 
5 or programs . 

In most databases, data is externally structured 
into tables. Each table generally includes a series of 
ra fields which define columns of the table. Each row of 

;jg the table comprises a single record. For each row of 

□ 

p 10 data in a table, a counterpart of that data is 

. s £3 physically stored in the database. Thus, when the 

j s . database user requests particular information from the 

H table, the appropriate portion of the stored data is 

S retrieved and presented to the user. 

O 15 A program referred to as a "database management 

system" ("DBMS") provides users with an interface to the 
database. The DBMS provides structure to the database 
that enables users to access information objects stored 
in the database. The DBMS identifies and retrieves 
2 0 certain information objects in response to information 
requests, or "queries" from a user. The retrieval of 
particular information objects depends on the 
similarity between the information stored in the 
information objects and requests presented to the 
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system by the user. The similarity is measured by 
comparing values of certain attributes attached to the 
information objects and information requests. 

For example, if a table named "Employee" contains 
5 the fields "Name", "Dept", "Age" and "Salary", and a user 
desires to find the subset of employees who work in the 
electronics department, the following query can be 

□ used: 

\Q SELECT Name, Salary, Age 

□ 10 FROM Employee 

Q WHERE Dept = "Electronics" 

ifj To facilitate the retrieval process, information 

n objects in a database are often "indexed" so that the 

\ u j 15 objects are characterized by assigning descriptors to 

j~ identify the content of the objects. The process of 

I IT " 

P characterizing these information objects, referred to 

as "indexing", can lead the DBMS to particular items in 
the database in response to specific queries from a 
20 user. 

To build an index for a table, the DBMS typically 
scans the table, retrieves the data from every row and 
column in the table, and adds the data to the index, 
which is often in the form of a B-tree structure. For 
25 more information on B-tree structures, see Patrick 
O'Neil "Database - Principles, Programming, 
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Perf ormance, n Morgan Kaufmann Publishers, Inc. (1994), 
incorporated herein by reference. The DBMS 

sequentially reads each and every data entry in the 
table, copies each data entry to a temporary space, 
5 sorts the data entries if necessary, and finally 
creates a data structure for the index. 

The process of building the index for the table, 
p however, generally consumes great amounts of time and 

\Q resources. For example, creating an index for a table 

o 

□ 10 having several million rows may take several days. 

SI 

xQ Moreover, creating the index for this table would 

h* 

„ typically require several hundred megabytes of 

□ 

i^l temporary workspace to copy and sort the data before 

Q 

^ creating the index. Naturally, the process of creating 

U 3 

j^f 15 or changing an index will take proportionally larger 

amounts of time. Tables for databases such as those 
used in data warehouses may have billions, or even 
millions of billions of rows. It may take the user 
weeks or even months to create the index for tables 
20 this size. 

Other factors compound the time problems 
associated with creating the index. Specifically, 
after the index is created, time is required for the 
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database to test the index and return performance 
statistics, and for the user to analyze those results. 

With a typical indexed database system, there are 
generally two steps to resolving a query. The first 
5 step is to determine which clauses in the query have 
associated descriptors or index entries in the index, 
to retrieve those index entries, and preliminarily 
restrict the set of information objects being 
considered. The second step generally involves taking 

10 the set of information objects from the first step and 
examining each information object in turn to determine 
if it satisfies the query. 

Structured Query Language (SQL) has evolved into 
a standard language for database queries or statements. 

15 An SQL interface allows users to formulate relational 
operations on database tables either interactively, in 
batch files, or embedded in host languages such as C, 
COBOL, etc. Operators are provided in SQL that allow 
the user to manipulate the data, wherein each operator 

20 operates on one or more tables and produces a new table 
as a result. 

In the process of tuning an SQL statement or 
query, the user often wishes to know how a change in 
indexing would affect the performance of that query. 
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As explained above, indices may be added to the 
database to facilitate the speed at which queries are 
executed, especially in larger tables where an index 
may make a substantial improvement in performance . On 
5 the other hand, due to the amount of data in the 
database, adding or changing an index may require 
considerable amounts of time and resources for the 
database to build the index. Thus, the user is often 
presented with the dilemma of either expending the time 

10 and resources required to build the index, at the risk 
of the new index not improving performance in any 
meaningful way, or not building the index, and risking 
the failure to recognize improved performance which 
might be possible with the index. 

15 Oracle database management systems provide users 

with the ability to view an "optimization plan" of a SQL 
statement. An optimization plan is automatically 
determined by the database for the SQL statement when 
the statement is parsed by the database. The 

2 0 optimization plan shows how the database would retrieve 
the data necessary to satisfy the requirements of the 
SQL statement without actually executing the SQL 
statement. Specifically, the optimization plan shows, 
among other things, information such as what table 
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would be first accessed, how intermediate result sets 
would be joined, whether an index would be used and, if 
so, how that index would be interpreted. Thus, by 
viewing the optimization plan for a particular SQL 
5 statement, the user may obtain an estimate as to how 
efficiently that SQL statement would be executed in the 
database . 

In larger database management systems, the 
optimization of queries becomes more important to 

10 minimize the amount of time and resources consumed. 

Thus, it becomes equally important for users to be able 
to view the optimization plan for an SQL statement and 
ascertain the effect index changes may have on the 
optimization plan. 

15 Fig. 1 is a flow diagram of a conventional method 

100 for viewing the effect of changes to an index for 
a database table on an optimization plan for an SQL 
statement. In step 110, an original optimization plan 
is created for the SQL statement. In step 12 0, the 

20 indices for a table referenced in the SQL statement are 
created, dropped or modified. In step 13 0, a new 
optimization plan is created for the SQL statement. 
Lastly, in step 140, the user compares the new 
optimization plan with the original optimization plan 
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to determine if performance would be improved or 

worsened as a result of the index changes. 

As explained above, however, conventional method 

100 of Fig. 1 requires excessive time and resources to 

5 create, drop or change the index. Moreover, excessive 

time and resources are then required for the database 

to gather the necessary statistics to build the various 

□ optimization plans. If the database is not used in a 

t£j production environment, taking the time to make changes 

□ 

p 10 to the index using conventional methods might be 



Mi 

□ 



possible. If the database is used in production, 
however, it would most likely not be feasible to expend 



ii 
□ 

; v l the time and energy needed make the changes shown in 



Fig. 1 due to the tremendous negative impact on speed, 
15 resources and overall performance. For example, using 
the methodology of Fig. 1, if a tool or application 
were relying upon an existing index, and the user 
changed or dropped that index in step 120, the database 
could shut down and the entire system could deadlock. 
20 Thus, with conventional methods for previewing the 

effect of index changes on optimization plans, the user 
is often compelled to minimize any experimentation with 
the index. This, in turn, often results in the failure 
to realize the optimal index topography or optimization 
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plan for the database which could cost great amounts of 
time and energy when the SQL statements are executed in 
the database, particularly for larger database 
management systems. Thus, there is a need for a faster 
5 and more efficient way to change indexing designs for 
database tables and to create optimization plans for 
these indexes . 

Summary 

10 The present invention allows a user to see how an 

optimization plan for a database query changes when a 
new index is added to a database table, an existing 
index is dropped from the table, or an existing index 
for the table is modified. 

15 A method and apparatus provide a framework for a 

user to experiment with the index topography for tables 
and preview the effects that the various topographical 
constructions of indexes can have on the optimization 
plan for a database query, such as an SQL statement, 

20 without having to dedicate the time and resources 
required by conventional methods. 

According to aspects of the present invention, a 
virtual table is created which mimics the structure of 
a table on the database under test, or "original table" 
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on the database. The virtual table is generally 
created by copying the original table, excluding any 
data in the original table. Thus, for example, if the 
data is stored in rows of the original table, the rows 
5 are not copied into the virtual table. Any existing 
indexes associated with original table, or "original 
indexes," however, are copied to define a virtual index 
associated with the virtual table. 

By excluding data when copying the original table 

10 to define the virtual table, the associated virtual 
index may be easily and quickly modified while 
preserving the overall structure of the original table. 
New indices may be added and existing indices may be 
dropped very quickly. Also, if no original index 

15 exists, a new virtual index may be easily created. 

In the query, references to the original table are 
replaced with references to the virtual . table. The 
database management system then determines a new 
optimization plan for the query. Because the new 

20 optimization plan is determined using the virtual table 
and virtual index, the plan is retrieved much faster 
than if it were created using the original table and 
any associated original index. This is because the 
actual data in the original table was excluded when the 
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original table was copied to define the virtual table. 
Thus, any changes to the optimization plan may be 
identified quickly after the indexing design is 
. altered. 

5 Before the new optimization plan is displayed for 

the user, any references in the new optimization plan 
to the virtual table and any virtual index are replaced 
with the names of the original table and the original 
index. In this way, the user can compare the new 
10 optimization plan with the original optimization plan 
and analyze the changes without concerning himself 
with, or even needing to know about, the use of virtual 
objects in creating the new optimization plan. 

15 Brief Description of the Drawings 

Fig. 1 is a flow diagram of a conventional method 
100 for viewing the effect of changes to an index for 
a database table on an optimization plan for a SQL 
statement; 

2 0 Fig. 2 is a block diagram illustrating an 

exemplary hardware environment in which exemplary 
embodiments of the present invention may be 
impl emen t ed ; 
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Fig. 3 is a block diagram illustrating a system 
for viewing the effect of changes to an index for a 
database table on an optimization plan for a database 
query, according to an exemplary embodiment of the 
5 present invention; and 

Fig. 4 is a flow diagram of a method for viewing 
the effect of changes to an index for a database table 
on an optimization plan for a database query, in 
accordance with an exemplary embodiment of the present 
10 invention. 

Detailed Description 
Fig. 2 is a block diagram illustrating an 
exemplary hardware environment in which exemplary 
15 embodiments of the present invention may be 
implemented. In the hardware environment of Fig. 2, a 
client computer 200 is coupled to a server computer 
202. Both the client computer 200 and server computer 
202 may include, inter alia, processors, random access 
2 0 memory (RAM) , read-only memory (ROM) , keyboard, 
display, fixed and/or removable data storage devices, 
and data communications devices. 

In Fig. 2, server computer 202 is in communication 
with a database 212 which is preferably an Oracle 
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database. As should be appreciated by those skilled in 
the art, other databases may be used such as Microsoft 
SQL Server databases, Sybase SQL Server databases, and 
IBM DB2 databases . 
5 Those skilled in the art will recognize that any 

combination of the above components described with 
reference to Fig. 2, or any number of different 
components, peripherals, and other devices, may be used 
with the client computer 200 and server computer 202. 

10 Those skilled in the art will also recognize that 
exemplary embodiments of the present invention may be 
implemented on a single computer rather than multiple 
computers networked together. 

Exemplary embodiments of the present invention are 

15 typically implemented using database management system 
software, such as the SQL- Station software made and 
sold by PLATINUM Technology, although it may be 
implemented with any database management system 
software such as the Developer/2000 package sold by 

2 0 Oracle or the DB2 product sold by IBM. Moreover, 
PLATINUM'S SQL-Station software, in which exemplary 
embodiments of the present invention may be realized, 
may be used in conjunction with other software such as 
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Oracle Developer/2000 software and the DB2 product sold 
by IBM. 

In Fig. 2, the software includes an SQL-Station 
client program 204 and Relational Extender client 
5 program 206 executed by the client computer 200. The 
software further includes an Oracle server program 208 
and Relational Extender program 210 executed by the 

□ server computer 202. These programs execute under the 
^0 control of an operating system on their respective 
!□ 10 computers 200 or 202, such as WINDOWS 95, WINDOWS NT, 
\Q OS/2, AIX, MVS, UNIX, etc. Those skilled in the art 

will recognize that any combination of the above 

Q 

Q programs, or any number of different programs, may be 

Q 

j|l used to implement exemplary embodiments of the present 

□ ' 
15 invention. 

The SQL-Station client program 204 and the 

Relational Extender client program 206 generate 

commands for performing various search and retrieval 

functions, i.e., queries, against the database 212 

20 managed by the Oracle server program 208 and the 

Relational Extender server program' 210. In the 

preferred embodiment, these queries conform to the SQL 

standard, although other types of queries could also be 

used without departing from the scope of the invention. 
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The queries invoke functions performed by the Oracle 
server program 2 08 and the Relational Extender server 
program 210, such as definition, access control, 
interpretation, compilation, database retrieval, and 
5 update of user and system data. 

Generally, DBMS software, the SQL queries, and the 
instructions derived therefrom, are all tangibly 
□ embodied in or readable from a computer- readable 

d medium, e.g. one or more data storage devices and/or 



SI 



P 
□ 



10 data communications devices. Moreover, the RDBMS 
software, the SQL queries, and the instructions derived 
therefrom, are all comprised of instructions which, 
when read and executed by the client computer 200 
and/or the server computer 202, causes the client 

15 computer 200 and/or the server computer 202 to perform 
the steps necessary to implement and/or use embodiments 
of the present invention. 

Fig. 3 is a block diagram illustrating a system 
for determining the effect of changes to an index for 

2 0 a database table on an optimization plan for a database 
query, according to an exemplary embodiment of the 
present invention. There are two users or "schemas" 
shown, namely "TUTOR" 302 and "PAFO-HR" 304, each of 
which have access to a database 3 06, which is 
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preferably an Oracle database such as the Oracle 8 
database. 

In Fig. 3, each user 302, 304 controls its own 
objects and information stored in tables within that 
5 user's account. For example, user PAFO-HR 304 controls 
original table 308 and an associated index 310, as well 
as virtual table 312 and a virtual index 314 associated 
with virtual table 312. The tables 308, 312 and the 
respective associated indexes 310, 314 are stored on 

10 the database. 

Each user 302, 304 generally controls information 
stored in that user's account to the exclusion of other 
users of database 306. Users may, however, be granted 
various privileges with respect to the accounts of 

15 other users. Generally, the privilege may only be 
granted from one user to another with respect to the 
one user's account. For example, in Fig. 3, only PAFO- 
HR 304 has the power to grant privileges on the PAFO-HR 
304 account to other users. 

20 One such privilege is "READ," that is, the 

permission to access information in another user's 
account. For example, in Fig. 3, user PAFO-HR 304 has 
given user TUTOR 3 02 permission, or granted TUTOR 302 
a READ privilege, to access information and objects 

Attorney Docket N0.PLATIOI8 MCF/ JGRIFFITH 
jgriffith/plat/1018/1018.001 



stored in tables in the PAFO-HR 304 account. Thus, 
TUTOR 302 is able to query the tables in PAFO-HR 1 s 
account and access such information in the PAFO-HR 304 
account. On the other hand, a third user "SCOTT" (not 
5 shown) has not been granted such READ privileges with 
respect to PAFO-HR' s account, so SCOTT cannot access 
tables controlled by PAFO-HR 304. 

Another such privilege available in the system of 
Fig. 3 is a " CRE ATE__TAB LE n privilege or set of 

10 privileges, which may also be granted from one user to 
another. The CREATE__TABLE privilege, if granted by the 
one user, allow other users to create tables in the one 
user's account, and to store objects in those tables. 

Users often do not wish to grant CRE ATE_TAB LE 

15 privileges to other users on a database system, because 
of the broad power it gives other users to unilaterally 
choose to modify or delete information stored within 
another user's account. Thus, in the database 
environment of Fig. 3, TUTOR 302 has not been granted 

20 CREATE_TABLE privileges with respect to PAFO-HR 1 s 
account . 

In Fig. 3, in accordance with exemplary 
embodiments of the present invention, a software 
package entitled "Plan Analyzer for Oracle" ("PAFO") 316 
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is stored on database 306. This software package is 
accessible by users 302, 304 of the database system. 
Unlike TUTOR 302, the package PAFO 316 has CREATE_TABLE 
privileges with respect to PAFO - HR 304 granted to PAFO 
5 316 along with several other privileges by the Database 
Administrator (DBA) . Thus, a user logged into the 
TUTOR 3 02 account who would otherwise not have 
privileges required to access and experiment with the 
tables and indices in the PAFO - HR 3 04 account, may use 

10 the PAFO package 316 to accomplish these tasks. 

In Fig. 3, TUTOR 3 02 calls the package PAFO 316 to 
execute methods of the present invention. When PAFO 
316 is called, PAFO 316 creates and dynamically deploys 
a procedure 318 to the PAFO - HR 304 account. The 

15 deployed procedure 318 is then executed in the PAFO - HR 
304 account. Deployed procedure 318 may then grant the 
necessary privileges for accessing the PAFO - HR 304 
account to the user of the TUTOR 302 account. The 
deployed procedure then grants READ (not write) 

20 privileges on the virtual table to TUTOR, the user's 
account. In this way, TUTOR can access both original 
table 308 and virtual table 312 without having the 
CREATE_TABLE privilege. The functionality of deployed 
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procediire 318 is hereafter described with reference to 
Figs . 3 and 4 . 

In step 402 of Fig. 4, procedure 316 identifies 
original table 308, as referenced in SQL statement 320, 
5 and copies original table 308 to define virtual table 
312. This copying, in step 402, includes copying the 
original table statistics to the new table, including 
the column statistics, histograms, and segment storage. 
In this way, it appears as if the virtual table 

10 contains as many rows of data as the original table. 

Any actual data in original table 308, however, is 
preferably excluded from the information copied to 
define virtual table 312. Thus, for example, when data 
is. stored in rows of original table 308, the rows are 

15 not copied into the virtual table 312. 

In step 402, the benefits of creating and working 
with a copy of the original table are many. Users 
accessing original table 308 are not disrupted and 
performance is not degraded by the changes. In a 

2 0 production environment, executing applications are not 
affected. When Oracle databases are used, nothing in 
the Oracle catalog needs to be modified for original 
table 308. Moreover, since the virtual table does not 
contain any rows, index creation is very fast. 
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In step 402, if other original tables are present 
in the PAFO-HR 304 account, these tables may also 
copied to define corresponding virtual tables. Also, 
for reasons which will become apparent below, a list 
5 (not shown) is preferably maintained in which the names 
of virtual tables are correlated with the original 
tables from which they were created. 
Q In step 404, virtual index 314, to be associated 

)0 with virtual table 312, is defined. In this step, if 

13 10 any original index 310 exists, associated with original 

ifij table 308, procedure 316 makes copies of original index 

El 310 to define virtual index 314. For example, if 

original indices are defined for the two columns shown 
in original table 308 of Fig. 3, corresponding virtual 
15 indices are created for the two columns shown in 
virtual table 312 by copying the original indices. 

The statistics associated with original index 310 
are also copied into virtual index 314, and may then be 
set as specified by the user. In this way, the virtual 
20 indices preferably have the same data structures as the 
original indices, including the same constraints and 
definitions. Thus, as far as any optimization plan is 
concerned, the structure of the virtual index is the 
same as the original index. 
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In step 404, if no original index 310 associated 
with original table 308 exists, virtual index 314 may- 
be created and defined by the user through procedure 
316. Also, in situations where a user wishes to 
5 experiment with no index, the user may simply choose to 
define virtual index 314 by deleting any indices 
present in original index 310, using deployed procedure 
316. At this point, procedure 318 is created on PAFO- 
HR 304 and executed to grant READ privileges to Tutor 
10 302. 

In step 406, after virtual index 314 is defined, 
PAFO 316 replaces in SQL statement 320 any reference to 
original table 308 with a reference to virtual table 
312. In addition, any reference to original index 310 

15 in SQL statement 320 is switched- with the name of 
virtual index 314. 

A modified SQL statement 322 with the replaced 
names is then sent to the database server. A user of 
account TUTOR 302 will believe he is accessing original 

20 table 308, while actually accessing virtual table 314. 

Moreover, by creating a copy of the original table and 
simply changing the name of that object as it is 
referenced in the SQL statement, the need for the time- 
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consuming and resource- consuming process of creating a 
new index on the original table is eliminated. 

Because the PAFO program 316 has altered SQL 
statement 320 to define modified SQL statement 322, the 
5 database interprets the modified SQL statement 322 to 
determine the new optimization plan 324 for the virtual 
table in step 408. 
O In step 410, information in new optimization plan 

*0 324 returned by the database server is then modified by 

□ 

Q 10 PAFO procedure 316 to define a modified optimization 

\Q plan 326. Specifically, any references in new 

i5 optimization plan 324 to virtual index 314 and virtual 

□ 

±j table 312 are replaced, respectively, with references 

Q 

Yj to original index 310 and original table 308. 

^ 15 The modified optimization plan 326, with the 

replaced names, is then displayed to the user in step 
412. Thus, to the user, it appears as though he is 
working only with the original objects 308 and 310. 
Using the methodology described above, the time 
20 required to make the changes to the index and retrieve 
the new optimization plan is often reduced from a 
matter of hours to a matter of seconds. Thus, the user 
simply enjoys improved speed and system performance in 
retrieving the new optimization plan without needing 
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to concern himself with, or even be aware of, the use 
of virtual tables and virtual indexes. 

The user may then compare modified optimization 
plan 326 with any original optimization plan created 
for original table 308 and original index 310. If the 
new optimization plan is more desirable, e.g., appears 
as if it would improve the speed and efficiency of the 
database in executing SQL statement 320, the user may 
then choose to actually build virtual index 314 on 
original table 308. Conversely, if performance would 
not be improved, the user may experiment with a 
different virtual index 314 or continue using original 
index 310 without having wasted the time and resources 
which would have otherwise been required to construct 
virtual index 314. 

Each of the functions described above, with 
respect to Figs. 3 and 4, can be performed 
simultaneously by multiple users on the same object. 
These functions do not interfere with other users of 
the objects, nor do they have a significant impact on 
performance, allowing them to be performed on a 
production system. 



Example 
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In one example, a user is logged onto the TUTOR 
302 account of Fig. 3. In this example, original table 
3 08 in account PAFO-HR 304 is a table storing the name 
of employees of a company or firm and, as such, is 
5 referred to hereafter as the "EMPLOYEES" table, TUTOR 
3 02 has been granted READ privileges with respect to 
PAFO-HR 1 s account, so TUTOR 302 is able to send queries 
to the EMPLOYEES table. 

Virtual table 312 has been created for the 
10 EMPLOYEES table where the virtual table name is 
"T_########l." Original SQL statement 32 0 is the 
following : 

SELECT * 

FROM hr. employees e 
15 WHERE hiredate > :H_Date 

The following SQL statement is sent to the server 

as modified SQL statement 322, with the original table 

name "EMPLOYEES" replaced with the virtual table name 

20 «t_########1:" 

SELECT * 

FROM hr. T_########l e 
WHERE hiredate > :H Date 
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If SQL statement 320 contains optimization hints, 

PAFO 316 check for hints containing original table name 

"EMPLOYEES" or one of the indexes associated therewith 

as parameters to the hints. For instance, assume the 

5 user is working with the following SQL statement 320: 

SELECT /*+ INDEX (e, I_EMP__HIREDATE) */ * 

FROM EMPLOYEES e 

WHERE hiredate > :H_Date 

10 When the user requests to view the optimization 

plan for SQL statement 320, the following message is 

sent to the database server as modified SQL statement 

322: 

SELECT /*+ INDEX (e, I_########5) */ * 
15 FROM hr.T_########l e 

WHERE hiredate > :H_Date 

In the interest of avoiding corruption in the 

system, each user is preferably only allowed to create 

20 a single copy of the EMPLOYEES table to define 
"T_########l," the virtual table. Each user is 
preferably restricted from creating a new copy if a 
copy is already created for that user. 

With the procedures described below, the name of 

25 the original table is preferably specified rather than 
the virtual table name. So, for example, if the user 
creates a first virtual index on the EMPLOYEES table, 
the user can create a second virtual index or drop an 
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index on the virtual copy of the EMPLOYEES table, but 

the table name parameter should be the name of the 

original table. In the latter case, where the user 

reuses a virtual table created before, the PAFO package 

5 ensures that the index names retrieved still exist on 

the original table. For example, the following SQL 

query, may be used: 

SELECT index_name FROM expl_indexes 
WHERE owner = : Index_Owner 
10 AND index_name = : Index_Name 

AND table_name = :Table_Name 

Finally, since only the names of indexes that 

existed on the original table are generally returned, 

15 the virtual indexes created should be queried with a 

statement such as the following: 

SELECT owner, index_name FROM expl_indexes 
WHERE table_owner « : Virtual__Table_Owner 
AND table_name = : Virtual_Table_Name 
20 AND (owner, index_name ) NOT IN 

{ ( "ownerl 1 , 1 indexl 1 ) , ( "owner2 1 , 1 index2 1 ) , ...) , 

where the pownerl 1 , ' indexl 1 ) pairs are the owner and 

name of the indexes returned. 

25 In this example, the following steps are used for 

viewing the effect of changes to an index for a 

database table on an optimization plan for a database 

query. 
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Step 1: Create Virtual Table 

The following procedure may be executed to create 
the virtual table, assuming a virtual table has not 
already been created: 
begin 

pafo. exp 1 ain_virtua 1 . cr eat e_vir tua 1_ table 
( : table_owner, : table_name) ; 
end; 

If the virtual table already exists, an error 
condition will be returned. The parameters are defined 
as follows: 



m 
□ 



15 



Bind 1 Mode 1 Datatype 1 Description 
Variable II 1 


table_owner 


Input 


VARCHAR2 (30) 


Name of the owner of 
the original table . 
This is for whom the 
virtual table will be 
created. 


table_ name 


Input 


VARCHAR2 (30) 


Name of the original 
table. 



Table I 



20 In Table 1, VARCHAR2 (3 0) represents a character 

string of up to 30 characters. Further, MODE = INPUT 
indicates data being input to the procedure. 
Conversely, as used in tables below, MODE = OUTPUT 
represents data being retrieved from the procedure. 



25 
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Step 2: De fine Virtual Table and Index Names 

After creating the virtual table, the following 
procedure may be executed to return the name of the 
virtual table and the names of the indexes that were 
5 copied to define virtual indexes, 
begin 

paf o . explain_virtual • get_virtual_table_aliases 
( : tab 1 e_owner , : t ab 1 e__name , : vi r tua 1_ t ab 1 e_name , 
: vir tualindexcount , : or iginal_index_owners , 

10 toriginal^index^names, : vi r tua l_index_name s ) ; 
end; 



Bind Variable 


Mode 


Datatype 


Description 


table_owner 
table name 
virtual_table__name 


Input 
Input 
Output 


VARCHAR2 (30) 
VARCHAR2 (30) 
VARCHAR2 (30) 


Owner of original table 
Name of original table 
Name used to create the 
virtual table . 


virtual_index_count 


Output 


INTEGER 


Number of indexes that 
existed on the original 
table. Each of these 
indexes was recreated 
on the virtual table 
but with a different 
name. 


original index owners 


Output 


Array of 
VARCHAR2 (30) 


Array of index owners. 
These names are the 
same for the original 
and virtual indexes. 
(Array size 

=:virtual index count) 


original_index_names 


Output 


Array of 
VARCHAR2 (30) 


Array of index names. 
These are the names 
used on the original 
table. (Array size=: 
virtual index count) 


virtual_index_names 


Output 


Array of 
VARCHAR2 (30) 


Array of index names. 
These are the names 
used to create the 
copies of the indexes 
listed in 

w original_index_names" . 
There is preferably a 
1-1 correspondence 
between the names in 
the"original_index_ 
names" and "virtual 
index_names" arrays . 
(Array size = : 
virtual index count) 




We 2 
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The call of step 2 generally assumes the virtual 
table was created using the CREATE_VIRTUAL_TABLE 
procedure. This means that if the virtual table exists 
in a cluster, that cluster is the same cluster in which 
5 the original table exists. That is, the virtual table 
is not the product of a request to make an unclustered 
table clustered. Otherwise an error is returned. 

step 3: Default Statistics 

10 The new virtual index preferably has realistic 

statistics in order to ensure that an optimization plan 
is created that is equivalent to having the index 
created on the original table. EXPLAIN__VIRTUAL provides 
the procedure DE FAULT_NEW_INDEX_S TATS to assist the user 

15 in setting the appropriate statistics. 

If the original table has existing indexes, the 
storage information and statistics of those indexes will 
be used to generate default storage information and 
statistics for the virtual index. If the existing 

2 0 indexes are not analyzed, limited default will be 
available. 

After executing DEFAULT_NEW_INDEX_STATS , the 
default storage information and statistics are returned 
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to PAFO for display and modification. The user is 
permitted to change these statistics to better identify 
the index properties. To help the user decide how to 
change the statistics, PAFO allows the user to display 
5 the statistics on other indexes currently created on the 
table. 

The following procedure may be executed to obtain 
the default statistics: 
begin 

10 paf o • explain_vir tual . def aul t_new_indexs tats 

( : tab 1 e_own e r , : t ab 1 e_name , : ind_name, : ind_col_names , 
: num_ind_co lumns , : def aul t_tablespace , : ini t_trans , 
:max_trans # :pct_free, :btree_levels, : leaf_blocks, 
: avg_leaf_blocks, : avg_data_blocks, : cluster_f actor , 

15 :blocks_allocated # :extents_allocated / 
:distinct_values) ; 
end; 



20 



25 



Attorney Docket N0.PLATIOI8 MCF/ JGRIFFITH 
jgrif f ith/plat/1018/1018 . 001 



The parameter definitions are as follows: 



Parameter 


Mode 


Datatype 


Usage 


table owner 


Input 


VARCHAR2{30) 


ORACLE account 
owning the 
table on which 
the index will 
be created. 


table name 


Input 


VARCHAR2 (30) 


Table name. 


ind name 


Input 


VARCHAR2(30) 


Name of 
propos ed i ndex 
to create. 


ind_col_names *1 


Input 


Array of VARCHAR2{30) 


Columns the 
index will be 
created for. 
The order of 
the columns in 
the array 
should match 
the order 
requested by 
the user. 


num_i nd_col umns 


Input 


NUMBER 


Number of 
columns; that 
is, the number 
of elements in 
the array, 
IND COL 
NAMES. 


def ault_tablespace 


Output 


VARCHAR2{30) 


Tablespace 
name on which 
the index will 
be created. 


init_trans 


Output 


Kl 1 JXA l") IT 1 1~1 

NUMBLK 


1N11 1KANS 

index . 


max_trans 


Output 


NUMBER 


MAX_RANS 
parameter for 
creating 
index . 


pct_f ree 


Output 


NUMBER 


PCT_FREE 
parameter for 
creating 
index. 


btree_l evels 


Output 


NUMBER 


Statistic that 
will be stored 
with the 
index . 


leaf blocks 


Output 


NUMBER 




avg leaf blocks 


Output 


NUMBER 




avg data blocks 


Output 


NUMBER 




cluster factor 


Output 


NUMBER 


\> 


blocks allocated 


Output 


NUMBER 




extents allocated 


Output 


NUMBER 




distinct values 


Output 


NUMBER 





*1 - ensure that the value for each array element 
is null terminated and specify in the appropriate OCT 
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bind parameter the array of actual lengths of each 
element. 

The following error codes may be generated when 
executing the procedure DEFAULT_NEW_INDEX_STATS . The 
5 second column contains a description of error and how, 
if possible, the user can resolve the error in 
parenthesis. 



-20001 


User is neither table owner; nor INDEX 
privilege on table; nor CREATE ANY INDEX 
privilege, (proper privileges should be 
obtained. ) 


-20002 


Table does not exist. (Check the table 
name and owner.) 


-20003 


Index already exists with specified 
columns. (The table already has an index 
with the requested columns.) 


-20004 


Column not found. (The index 
column does not exist . ) 


-20005 


Invalid table owner. (The Oracle account 
entered for the table owner does not 
exist . ) 


-20006 


Index name is not unique. (Enter a 
different index name for the virtual 
index. ) 


-20010 


First perform CLEAN_UP on the table. 
(The table already has a virtual index 
created by the user. 



Table 4 



The output parameters will be input to the next 
20 procedure executed, EXPLAIN_VIRTUAL . 

CREATE_VIRTUAL_INDEX . Also, note that it is possible 
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the user will attempt to create the index on a 
tablespace to which the user does not have access. 

Step 4: Create Virtual Index 

5 Any existing indexes of the original table are 

preferably copied to define the virtual index. The 
^ index statistics and storage information are also 

s 

? copied. To this end, the following procedure may be 

Ef 

^ executed: 

if 10 begin 

paf o . explain_vir tual . crea te_virtual_index 

I s * ( : table_owner, :table_name, : ind_name, : ind_col_names, 

li _ : num_ind_columns , : def ault_tablespace, : init_trans # 

Q :max_trans, :pct_free, :btree_levels # : leaf_blocks, 

Sj 15 :avg_ leaf_blocks, :avg_data__blocks / : cluster_f actor, 

□ :blocks_ allocated, : extent s_allocated, 

n\ :distinct_values) } 
end; 



20 The parameters are defined above in step 3. 

Step 5 : F inal Step 

At this point, PAFO creates a new WHAT IF frame as 
described above displaying the original SQL text. The 
user is allowed to modify the text and add hints. The 
25 "tag" from the SQL frame is copied and the same 
sequential number is used. For instance, if the SQL 
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Frame label is SQL: HISTORY; 1, then the WHAT IF Frame 
should be labeled, WHAT IF: HISTORY; 1. 

When the user requests an optimization plan, PAFO 
should alter the SQL text that is explained, BUT not on 
5 the SQL frame. Nonetheless , the SQL should look like 
the original SQL statement. Thus, the procedure 
desirably makes a copy of the SQL text and replace all 
occurrences of the original table name ( : table_name) 
with the table copy's name { : temp_table_name) . 

10 If the SQL statement uses a synonym (local or 

public) to point to the original table, the modified SQL 
text should include both the owner of the virtual table, 
and the virtual table name. Hint parameters may also 
need to be changed if the hints reference the table or 

15 an index on the table. The plan is then created and 
retrieved into memory. 

For each OBJECT_OWNER and OBJECT_NAME combination, 
where the OPERATION column starts with "TABLE 1 , the 
temporary table name should be changed to the original 

20 name ( : table_name) . 

For each of the virtual indexes returned in step 
2 above, the optimization plan should be searched for 
these virtual index names and replaced with the original 
index name. The virtual indexes are identified in the 
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arrays ( :original_index_owners, :original_index__names) . 
The associated replacement index names are stored in the 
array ( : virtual__index__names) . So PAFO searches each 
step where the OPERATION column starts with the text 
5 "INDEX". If the OBJECT_OWNER and OBJECTJSTAME match the 
ORIGINAL_INDEX_OWNER ( 0 ) and V I RTUAL_ I ND EX_NAME ( 0 ) 

values, the index name should be changed to 
ORIGINAL_INDEX_NAME ( 0 ) . This is preferably repeated for 
each of the array elements. 

10 The modified plan is then displayed, and the user 

is informed if the virtual index created had an effect 
on performance. 

When displaying the information in the "OBJECT" 
tab, PAFO preferably makes the same changes as described 

15 above in steps 4 & 5; that is, PAFO displays the indexes 
for T_########l, not EMPLOYEES. But PAFO should use the 
name EMPLOYEES instead of Tl when displaying the 
information to the user. Also, when displaying the 
indexes, the associated ORIGINAL__INDEX__NAME values 

20 should be displayed. 

When the user clicks on a step of the plan that 
contains either the virtual table name or one of it's 
indexes, the statistics for the associated virtual index 
should be displayed. Thus, the user clicks on 
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EMPLOYEES , the user sees the name EMPLOYEES, but PAFO 
lists the statistics for T_########l. The same holds 
true for the indexes on EMPLOYEES. 

Dropping a Virtual Index 

5 The only indexes that can be dropped by this 

procedure are preferably those belonging to a virtual 
table. So if a virtual table does not exist, it should 
be created. The virtual table is created via the 
procedure CREATE_VIRTUAL_TABLE . Then the user may 
10 indicate from which table he wishes to drop an index. 
The following steps may then be used: 

Step i. List All Ta bles to Which the User Has Access 

SELECT owner, table_ name 
FROM expl__ tables 

15 Step 2. Determine if the Selected Table is Virtual 

SELECT table — id, new_table_name 
FROM my_explain_virtual_tables 
WHERE orig_table_name = : Table name 

20 If the query returns a row, then the virtual copy 

exists. Otherwise, create the virtual table (see step 
1 in Creating Virtual Index above) . 
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fit-.pp 3 . List Virtual Indexes on Virtual Table 

List the virtual indexes on the virtual table (see 
step 2 in Creating Virtual Index above) - 



□ 



hh 4 



10 



15 



Step 4. Drop the Virtual Index 

To drop one of the virtual indexes, perform the 
following procedure: 
begin 

paf o . explain virtual . drop_virtual_index ( : tab 1 e_owner , 
: table__name, : vi r tua l_index_name ) 
end; 



Parameter 


Mode 


Datatype 


Usage 


t ab 1 e_owne r 


Input 


VARCHAR2 (30) 


ORACLE account owning the 
original table. 


table name 


Input 


VARCHAR2 (30) 


Name of the original table . 


index_name 


Input 


VARCHAR2 (30) 


Name of the virtual index; 
(EXPLAIN__VIRTUAIi_INDEXES . 
NEW INDEX NAME) 



Table 5 



CI fianina Up 

2 0 To drop a specific virtual table and clean up the 

associated information in the PAFO repository, the 
following procedure may be executed: 
begin 

pafo . explain_virtual . clean_up_table 
25 ( : virtual_table_ creator, s original_table_owner , 

:original_ table_name) ; 
end; 
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Q 
Q 

'. - -3 

: - 



m 



Parameter 


Mode 


Datatype 


Usage 


virtual_table_owner 


Input 


VARCHAR2 (30) 


ORACLE account 
that created the 
virtual table . 


original_table_owner 


Input 


VARCHAR2 (30) 


ORACLE account 
that owns the 
original table . 


or i g i na 1__ t abl e_name 


Input 


VARCHAR2 (30) 


Name of the 
original table . 



Table 6 

To drop all virtual tables, execute the following: 

10 begin 

paf o . explain_vir tual - clean_up_all ; 
end; 

It should be understood that the particular 
15 embodiments described above are only illustrative of the 
principles of the present invention, and various 
modifications could be made by those skilled in the art 
without departing from the scope and spirit of the 
invention. Thus, the scope of the present invention is 
20 limited only to the extent of the claims that follow. 
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